1. Field of the Invention
The present invention relates generally to electronic-commerce and electronic-services and, more particularly, to a modeling tool for development of electronic-services, methodologies related to the tool, uses of the tool, and an electronic-service employing the tool.
2. Description of the Related Art
In the state of the art, the Internet is not only being used to provide information and perform electronic commercial business transactions ((business-to-business and customer/client-to-business; hereinafter “e-commerce”), but also as a platform, or set of discrete platforms, through which services and products are delivered to businesses and customers. (Depending on the context, “Internet” or “internet” is used herein as both a specific and generic term for any collection of distributed, interconnected networks (ARPANET, DARPANET, World Wide Web, or the like) that are linked together by a set of industry standard protocols (e.g., TCP/IP, HTTP, UDP, and the like) to form a global, or otherwise distributed, network.) The recent development of large numbers and types of electronic-services (hereinafter “e-service(s)” or “ES”), as well as of electronic-service providers, sets out a need for mechanisms and frameworks that support providers in developing and delivering e-service and support consumers in finding and accessing those e-commerce businesses and any related physical business outlets. Thus, software vendors and industry consortia are providing models, languages, and tools for describing e-services and making them available to users. Such tools and frameworks usually allow the specification of specific e-services in terms of their inherent properties, which can be generic (such as the electronic-service name and location, e.g., fictitious Acme Cars) or service item specific (such as the car size for a car rental service). Depending on the framework, the properties are generally represented by Java vectors or XML documents. In addition, software vendors provide software platforms (“E-Service Platform,” or simply “ESP”) that allow service providers to register and advertise their services and allow authorized users to lookup and access registered electronic-services.
FIG. 1 (Prior Art) is a schematic representation of such a ESP system. Examples of commercially available platforms are BEA Web Logic Collaborate™, WebMethods Enterprise™, Sun Microsystems Jini™, IBM WebSphere™, and present assignee Hewlett-Packard Company's HP™ e-speak™ ESPs 100 (further details being available at http://www.e-speak.hp.com). Ovals 103 labeled “ES” represent specific E-Service(s) 103. An exemplary Service Provider 105, such as a public transportation related corporation, may register a plurality of generic services: buying cars, renting cars, selling cars, van or bus services, limousine services, and the like, each being a specific individual E-Service 103. An E-Service Platform 100 itself may be coupled to other platforms 101 for subsidiary or specialized E-Service(s) 103, such as those which are internal operations of the E-Service Platform related business itself. This platform approach enables the uniform representation, search, and access of business applications, both those used for internal operations (such as access to databases or other enterprise applications and the like as would be known in the art) and the ones that are made available to customers, Client 107, typically via the Internet at an Internet address. ESPs 100, 101 typically allow Service Providers 105 to register specific electronic-services, each represented as an ES 103 oval symbol, and allow authorized Clients 107 to lookup and invoke registered electronic-services. In order to make electronic-services searchable and accessible to customers, Service Providers 105 (or other user in the case of a sub-platform 101) must register each service definition with an ESP 100, 101 (and possibly with other advertising services (not shown)). As part of the registration process, the Service Provider 105 gives information about each electronic service, such as the service name, the methods (operations) that can be performed on the service along with their input/output parameters, the list of authorized users, and the like. Note that an electronic-service may provide several methods (operations) to be invoked as part of its internet interface; for instance, an e-music service may allow users to browse or search the catalog, to listen to songs, or to buy discs or downloadable mp3 files. In addition, a Service Provider 105 specifies who is the handler of the service, i.e., the application or server that must be contacted in order to request actual service executions. (“Client”-“Browser”, “Server” terms are used as the standard model of interaction in a distributed computer network system in which a program at one site sends a request to another site and then waits for a response. The requesting program is called the “client,” or “browser” and the program which responds to the request is called the “server.”) Depending on the service model and the ESP 100, 101, the service handler can be identified by providing a linking Universal Resource Indicator (“URI ”)—such as in HP e-speak form—or by giving a proxy Java object that will take care of contacting the handler—such as in Jini.
Customers 107 may look for available electronic-services by issuing service selection queries that may simply search electronic-services by name or that can include complex constraints on the service properties as well as ranking criteria in case multiple electronic-services satisfy the search criteria (e.g., not just Acme Car Rentals (fictitious) but Acme Car Rentals, midsize, San Jose airport, this Saturday night. Service selection queries return a reference to one or more electronic-services that can be used to invoke them.
The uniform representation and implementation of applications according to a homogeneous e-service framework creates a need for methods, devices, and tools for composing individual, web-accessible E-Service (possibly offered by different provider companies) into pre-packaged, value added, “composite e-service,” where a composite e-service service is a service composed of more than one individual service and inherent methods thereof. For instance, a provider 105 having an appropriate tool could offer a travel reservation service by composing hotel and flight reservation services, or it could offer an itinerary planning service by composing road map services, weather services, traffic prediction services, and “utility” services to collect data from the user via the web or to send e-mail notifications.
One current approach to structuring work item processes is generally referred to as “traditional subprocess” coding. Each individual context of the process has to be maintained in ad-hoc ways by the process developer, who has to define ad-hoc variables for this purpose. Explicit nodes of a flow diagram for such a one-level processing architecture must be included in the process definition just for the sake of searching subprocesses to interact with. For complex services, process/subprocess coding is extremely complex and necessarily proprietary to the specific service for which it was developed. Upgrading and maintenance requires specific knowledge and understanding of the specific program.
Another current approach to providing a composition facility, advocated by workflow and Enterprise Application Integration (“EAI”) vendors, consists in offering a development environment targeted mainly to the enterprise's information technology (“IT”) personnel. Basically, in another one-level modeling structure, a service provider specifies the flow of service invocations (i.e., the electronic-services to be invoked, their input and output data specification, and their execution dependencies). A workflow developer specifies the flow of the work, i.e., the work items to be executed (where a work item represents the invocation of a business function and is a black box from the workflow viewpoint), their input and output data specifications, and their execution dependencies. Exemplary traditional workflow management systems such as MQ Workflow (IBM. MQ Series Workflow—Concepts and Architectures (1998)), InConcert (Ronni T. Marshak. InConcert Workflow. Workgroup Computing report, Vol. 20, No. 3, Patricia Seybold Group (1997)), or Staffware2000 (Staffware Corporation, Staffware2000 White Paper (1999)), nor among newly developed, open, XML—and web-based systems such as Forte' Fusion (J. Mann. Forte' Fusion. Patricia Seybold Group report (1999)) and KeyFlow (Keyflow Corp. Workflow Server and Workflow Designer (1999)), are commercially available. Packaged Workflow Management System (WfMS) and problems associated therewith in contrast to the present invention are discussed hereinafter.
The problem issues are similar to proprietary process/subprocess coding. To complicate matters even further, in the e-service virtual world, an E-Service 103 may have several states and several state transitions caused by any individual interaction.
As shown in FIG. 1A (Prior Art), to describe a simple generic interaction flow 111 in an ad-hoc manner results in a complex, tangled spaghetti-like, workflow (even without showing in this simple example all of the subprocesses which are involved within each process node 113 and decision node 115 (and showing only successful decision flow paths)). Such one-level workflows are difficult to design and maintain. Alternatively, one must do hard-coding of the flow logic.
It has been discovered by the present inventors that at a generic level an E-Service 103 access requires: (1) operations to be performed at the service level (e.g., search, authentication, service-level exceptions, and the like) and (2) operations to be performed at the interaction, or method invocation, level (e.g., the invocation of the method and the handling of method-level exceptions, and the like). Although composite electronic-services could be developed by hard-coding the business logic using some programming language, Service Providers 105 would greatly benefit from a composition tool that could ease the tasks of (1) composing E-Services, (2) managing and monitoring them, and (3) making them available to authorized service provider users. In addition to such a tool, there is also need for an approach that consists in providing composition functionality as an e-service itself (or, rather, a meta-service, since it is a service for developing electronic-services); moreover, by providing a new e-service composition functionality as an e-service itself, the service composition facility can be advertised, discovered, delivered, managed, and protected by end-to-end security analogously to any other e-service, thereby exploiting all the advantages and features provided by the ESP 100. In addition, the ability of defining and deploying composite electronic-services is not limited to the ESP 100's owner, but can be offered to other providers, businesses and customers, thereby relieving them from the need of maintaining a composition system that may be onerous to buy, install, and operate. Hereinafter this meta-service e-service is referred to as Composition E-Service, or simply “CES.”
There is a need for the design, architecture, and implementation of a composition tools, models, and e-services for developing composite e-services.